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Remarks 

Applicants appreciate the Examiner's indication that claims 3, 4, 15, and 
16 define allowable subject matter. Additionally, in the outstanding Office Action, 
the Examiner rejects claims 1, 5-7, and 18-22 under 35 U.S.C. § 102(e) as being 
anticipated by U.S. Patent No. 6,647,019 to McKeown et al. ("McKeown"); rejects 
claims 8-13, 17, and 25 under 35 U.S.C. § 103(a) as unpatentable over 
McKeown in view of U.S. Patent No. 6,477,169 to Angle et al. ("Angle"); rejects 
claims 2 and 23 under 35 U.S.C. § 103(a) as unpatentable over McKeown in 
view of U.S. Patent No. 6,487,213 to Chao ("Chao"); rejects claims 14, 24, 26, 
and 27 under 35 U.S.C. § 103(a) as unpatentable over McKeown, Angle, and 
Chao; and rejects claim 25 under 35 U.S.C. § 103(a) as unpatentable over 
McKeown in view of Angle, Chao, and U.S. Patent No. 6,807,594 to Sindhu et al. 
("Sindhu"). Further, the Examiner rejects claim 14 under 35 U.S.C. § 1 12, 
second paragraph. 

By this Amendment, Applicants amend claims 1 and 14 to improve form. 
Applicants submit that claim 14, as amended, is clear and definite under 35 
U.S.C. § 112, second paragraph, and the rejection of this claim under 35 U.S.C. 
§ 112, second paragraph, is obviated. 

Rejection of Claims 1, 5-7, and 1 8-22 
under 35 U. S.C. § 1 02(e) Based on McKeown 

Claim 1, as amended, is directed to a network device including a credit 

counter, a request component, and a fake request circuit. The credit counter is 

configured to store a value indicating an amount of data eligible to be transmitted 
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from the network device. The request component is configured to generate 
requests to send data and to receive corresponding grants in response to the 
requests. The request component decrements the credit counter when the 
requests are generated and increments the credit counter when grants are 
received. A fake request circuit generates fake requests that cause grants to be 
returned to the request component. 

A proper rejection under 35 U.S.C. § 102 requires that a single reference 
teach every aspect of the claimed invention either explicitly or impliedly. Any 
feature not directly taught must be inherently present See M.P.E.P. § 2131. 
McKeown does not disclose or suggest the combination of features recited in 
Applicants' claim 1 . 

McKeown does not disclose or suggest, for example, the fake request 
circuit recited in claim 1 , which is "configured to generate fake requests, the fake 
requests causing grants to be returned to the request component." Applicants 
note that a fake request, as used in the pending specification and claims, defines 
more than just a "regular" request. The concept of a fake request is described in 
many locations in the as-filed application, and Applicants particularly draw the 
Examiner's attention to paragraphs 0047 and 0050. 

The Examiner contends that McKeown discloses the fake request circuit 
recited in claim 1, and particularly points to column 15, lines 18-26 and column 
15, lines 60-67 of McKeown. (Office Action, page 3). Applicants respectfully 
disagree with the Examiner's interpretation of McKeown. Although McKeown 
does recognize that request cells or grant cells may be dropped, (McKeown, 
column 15, lines 18 and 19), McKeown does not attempt to solve this problem 
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using a fake request circuit, as recited in claim 1. Instead, McKeown discloses 

transmitting a control cell that provides control information. The feature of 

McKeown is discussed in detail at column 15, lines 18-26: 

With regard to minimizing the effects of an LCS-2 request cell or 
grant cell becoming dropped, a periodic LCS-2 request (control) 
cell, containing control packet information, is transmitted by linecard 
330a to port module 340a to correct any of these inconsistencies by 
providing the current value of a certain request counter that is 
associated with a specific cell queue within port module 340a. 

This "LCS-2 request (control) cell" of McKeown are not fake requests , which 

cause "grants to be returned to the request component," as recited in claim 1 . 

Instead, the LCS-2 request (control) cells of McKeown are clearly described as 

containing "control packet information" that is used by destination port module 

340a to correct inconsistencies by "providing the current value of a certain 

request counter." Thus, these request cells of McKeown cannot reasonably be 

said to correspond to fake requests, much less fake requests that cause grants 

to be returned to a request component. 

In addition to pointing to the above-quoted section of McKeown, the 

Examiner also points to column 15, lines 60-67 of McKeown as being 

relevant to the fake request circuit recited in claim 1 (Office Action, page 

3). This section of McKeown further defines the LCS-2 request (control) 

cell. In particular, this section of McKeown states, in part: 'When linecard 

330a receives an LCS-2 grant cell response from port module 340a, 

linecard 330a transmits a new LCS-2 request (control) cell, which includes 

control data within the cell data field." (McKeown, column 15, lines 64-67). 

This section of McKeown further confirms that the LCS-2 request (control) 
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cell includes control data. The LCS-2 request (control) cell of McKeown is 
not a fake request, as recited in claim 1 . 

For at least these reasons, Applicants submit that McKeown does 
not disclose or suggest each of the features of claim 1, and the rejection of 
this claim under 35 U.S.C. § 102(e) should therefore be withdrawn. 
Claims 5-7, which depend from claim 1 , also stand rejected under 35 
U.S.C. § 102(e) based on McKeown. Applicants submit that the rejection 
of these claims should also be withdrawn, at least by virtue of their 
dependency from claim 1 . 

Independent claim 18 and its dependent claims 19-22 also stand rejected 
under 35 U.S.C. § 102(e) based on McKeown. 

Claim 18 is directed to a method of metering data flow to a network. The 
method includes receiving at least one data unit for transmission on the network; 
generating a request to transmit the data unit when a credit counter contains 
sufficient credits for the data unit; decrementing the credit counter in response to 
generating the request to transmit the data unit; receiving grant messages from 
the network that correspond to the transmitted requests, the grant messages 
indicating that the data unit may be transmitted on the network; and incrementing 
the credit counter in response to receiving the grant messages. The method of 
claim 18 additionally includes periodically generating a fake request that does not 
correspond to a data unit, the fake request causing grant messages to be 
received from the network and the credit counter to be incremented in response 
thereto. 
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Applicants submit that McKeown does not disclose or suggest each 
feature of claim 18. In particular, McKeown does not disclose or suggest 
periodically generating a fake request that does not correspond to a data unit, the 
fake request causing grant messages to be received from the network and the 
credit counter to be incremented in response thereto, as recited in claim 18. The 
Examiner states that the "LCS-2 request (control) cell" of McKeown corresponds 
to the fake request that is recited as being generated in claim 18. (Office Action, 
page 4). As previously discussed, Applicants submit that the LCS-2 request 
(control) cell cannot reasonably be said to correspond to a fake request. The 
LCS-2 request (control) cell is not a fake request, but is instead a control cell that 
includes specific control information for the receiving device. Accordingly, 
Applicants submit that McKeown does not disclose or suggest, as recited in claim 
18, periodically generating a fake request that does not correspond to a data unit, 
the fake request causing grant messages to be received from the network and 
the credit counter to be incremented in response thereto. 

For at least these reasons, Applicants submit that McKeown does 
not disclose or suggest each of the features of claim 18, and the rejection 
of this claim under 35 U.S.C. § 102(e) should therefore be withdrawn. 
Claims 19-22, which depend from claim 18, also stand rejected under 35 
U.S.C. § 102(e) based on McKeown. Applicants submit that the rejection 
of these claims should also be withdrawn, at least by virtue of their 
dependency from claim 18. 
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Rejection of Claims 8-13, 17, and 25 under 
35 U.S.C. § 103(a) Based on McKeown and Angle 

Independent claim 8 is directed to a request controller for metering data 
flow to a network. The request controller includes a real request vector 
component and a fake request vector component. The real request vector 
component generates request messages corresponding to data that is to be 
transmitted to the network and receives back grant messages indicating that the 
data can be transmitted to the network. The fake request vector component 
generates fake request messages to a destination on the network determined by 
a value in a pointer register. The pointer register is incremented after each fake 
request message is generated. 

The Examiner contends that McKeown discloses many of the features 
recited in claim 8 but concedes that McKeown does not "teach the real request 
and fake request are of vector form." (Office Action, page 6). 

Applicants respectfully disagree with the rejection of claim 8 based on 
McKeown and Angle. More specifically, Applicants submit that McKeown and 
Angle, even if combined, still do not disclose or suggest each of the features 
recited in claim 8. Neither McKeown nor Angle, either alone or in combination, 
discloses or suggests, for example, the fake request vector component of claim 
8, which generates fake request messages to a destination on the network 
determined by a value in a pointer register. As previously discussed, Applicants 
submit that McKeown does not disclose or suggest the generation of fake 
requests. The LCS-2 request (control) cell is not a fake request, but is instead a 
control cell that includes specific control information for the receiving device. 
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Accordingly, Applicants submit that McKeown does not disclose or suggest, as 
recited in claim 8, a fake request vector component that generates fake request 
messages to a destination on the network determined by a value in a pointer 
register. 

Applicants have reviewed Angle, and submit that Angle does not cure the 
above-noted deficiency of McKeown. Accordingly, even if McKeown and Angle 
were combined as the Examiner suggests, the combination would still not 
disclose or suggest each of the features recited in claim 8 and the rejection of 
this claim should therefore be withdrawn. The rejection of claims 9-13 and 17 
based on McKeown and Angle should also be withdrawn, at least by virtue of the 
dependency of these claims from claim 8. 

The Examiner additionally rejects claim 25 under 35 U.S.C. § 103(a) 
based on McKeown and Angle. Applicants submit that this rejection is improper 
and should be withdrawn because claim 25 depends from claim 24 and claim 24 
is rejected based on McKeown, Angle, and Chao. It appears to Applicants that 
the inclusion of claim 25 in this rejection was a typographical error. 

Rejection of Claims 2 and 23 under 35 U. S. C. § 103(a) 
Based on McKeown and Chao 

Claim 2 further defines the network device of claim 1 , and recites "an 
arbiter connected to the request component and to the fake request circuit, the 
arbiter combining the requests from the request component and the fake request 
circuit and transmitting the combined requests." The Examiner concedes that 
McKeown does not disclose the arbiter of claim 2, but contends that the arbiter of 
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claim 2 would have been obvious to one of ordinary skill in the art in light of 
Chao. (Office Action, page 10). Applicants respectfully traverse this rejection. 

Chao is directed to methods and apparatus for fairly arbitrating contention 
for an output port of a switch or router. (Chao, column 1 , lines 18-21). Although 
Chao may disclose an arbiter, nothing in Chao or McKeown suggests why one of 
ordinary skill in the art would use the arbiter disclosed by Chao to arbitrate the 
LCS-2 request (control) cells of McKeown (which the Examiner contends 
correspond to the generated fake requests of claim 1) and other requests of 
McKeown. The Examiner states that it would have been obvious to use the 
arbiter of Chao "in order to reduce the traffic congestion of requests outputting 
into the network." (Office Action, page 10). Nothing in McKeown however, 
suggests that the requests generated by McKeown are congested in being output 
to the network. Therefore, the Examiner's allegation lacks merit. 

For at least these reasons, in addition to the fact that claim 2 depends 
from claim 1 , Applicants submit that the rejection of claim 2 is improper and 
should be withdrawn. 

Claim 23 is dependent on claim 18 and recites "combining the requests 
and the fake requests into a combined request; and transmitting the combined 
request to the network." For reasons similar to those given for claim 2, 
Applicants submit that the combination of McKeown and Chao do not disclose or 
suggest the features of this claim. Accordingly, Applicants submit that the 
combination of McKeown and Chao would not disclose each of the features 
recited in claim 23 and the rejection of this claim should therefore be withdrawn. 
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Rejection of Claims 14, 24, 26, and 27 under 35 O.S.C. § 103(a) 
Based on McKeown, Angle, and Chao 

Dependent claim 14 depends from claim 8 and further recites "an arbiter 
connected to the real request vector component and to the fake request vector 
component, the arbiter combining the request messages from the real request 
vector component and the fake request vector component and transmitting the 
combined requests to the network." The Examiner relies on Chao to disclose the 
features of claim 14. 

For reasons similar to those given above regarding claims 2 and 23, 
Applicants submit that Chao does not cure the deficiencies of McKeown and 
Angle as applied to claim 8. Additionally, one of ordinary skill in the art would not 
have found it obvious to modify McKeown and Angle to include an arbiter 
disclosed by Chao. For at least these reasons, Applicants submit that the 
rejection of claim 14 is improper and should be withdrawn. 

Independent claim 24 is directed to a fabric request controller for metering 
data flow to a switch fabric, the fabric request controller includes means for 
generating a request vector, means for receiving grant messages, fake request 
generation means, and arbitration means. 

Applicants submit that McKeown, Angle, and Chao, either alone or in 
combination, do not disclose or suggest each of the features recited in claim 24. 
None of these references discloses or suggests, for example, "fake request 
generation means for periodically generating a fake request vector to one or 
more destinations on the switch fabric." The Examiner contends that the fake 
request generation means is disclosed by McKeown. As previously discussed, 
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however, McKeown does not generate fake requests, and therefore could not 
disclose or suggest the fake generation means recited in claim 24. Angle and 
Chao do not cure this deficiency of McKeown. 

For at least these reasons, the rejection of claim 24 based on McKeown, 
Angle, and Chao is improper and should be withdrawn. The rejection of claims 
26 and 27 are also improper and should be withdrawn, at least by virtue of their 
dependency from claim 24. 

Rejection of Claim 25 under 35 U.S.C. § 103(a) 
Based on McKeown, Angle, Chao, and Sindu 

Claim 25 depends from claim 24. In rejecting claim 25, the Examiner 

additionally relies on Sindu. Applicants submit that this is not a proper rejection 

under 35 U.S.C. § 103(a), as Sindu does not qualify as prior art under 35 U.S.C. 

§ 103(a). 35 U.S.C. § 103(c) qualifies 35 U.S.C. § 103(a) and states: 

(c) Subject matter developed by another person, which qualifies as 
prior art only under one or more of subsections (e), (f), and (g) of 
section 102 of this title, shall not preclude patentability under this 
section where the subject matter and the claimed invention were, 
at the time the invention was made, owned by the same person or 
subject to an obligation of assignment to the same person. 

(35 U.S.C. § 103(c)). Sindu qualifies as prior art under 35 U.S.C. § 102 only 
under subsection (e), and Sindu and the pending application are both assigned 
to Juniper Networks, Inc. Accordingly, Sindu is not available to preclude 
patentability under 35 U.S.C. § 103(a). For the Examiner's reference, Applicants 
note that Sindu is not available under 35 U.S.C. § 102(a) as the language "known 
or used by others" refers to knowledge or use which is available to the public. 
See MPEP § 2132. Sindu's publication date of October 19, 2004, is after the 



19 



Serial No.: 09/985,683 
Docket No.: 0023-0032 



filing date of the present application. Therefore, Sindu does not qualify as prior 
art under 35 U.S.C.§ 102(a) 



In view of the foregoing amendments and remarks, Applicants respectfully 
request the Examiner's reconsideration of this application, and the timely 
allowance of the pending claims. 

To the extent necessary, a petition for an extension of time under 37 CFR 
1.136 is hereby made. Please charge any shortage in fees due in connection 
with the filing of this paper, including extension of time fees, to Deposit Account 
No. 50-1070 and please credit any excess fees to such deposit account. 
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